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FOREWORD 


This  strategy  document  is  one  of  eight  functional  task  area 
strategies  produced  by  the  STARS  Joint  Task  Force.  All  of  the  docu¬ 
ments  produced  by  the  Task  Force,  including  the  general  STARS  Program 
Strategy  document,  are  listed  in  the  STARS  Joint  Task  Force  Report. 

This  document  identifies  the  scope,  sub-objectives  and  stra¬ 
tegies  designed  to  provide  the  conceptual  approach  for  accomplishment 
of  the  STARS  Program  objectives  in  the  project  management  functional 
task  area.  It  identifies  and  describes  the  high-level  activities, 
products  and  capabilities.  In  order  to  provide  full  understanding, 
background  and  rationale  material  is  sometimes  covered  that  is  also 
in  STARS  Program  Strategy. 

These  functional  task  area  strategy  documents  do  not  attempt  to 
delineate  the  detailed  plans,  costs  and  procedures  for  bringing  the 
proposed  products  and  capabilities  into  being  and  do  not  identify  the 
form  of  the  particular  projects  that  will  undertake  the  work  nor  the 
organizations  in  which  the  work  will  be  accomplished.  Instead,  these 
strategies  are  intended  to  guide  the  process  of  such  implementation 
planning  and  accomplishment. 

Indeed,  because  of  the  high  degree  of  linkage  among  the  func¬ 
tional  task  areas,  implementation  plans  and  acquisitions  may  well 
combine  related  capabilities  and  products  across  areas.  Individual 
projects  may  tackle  only  part  of  one  subtask  from  a  functional  area 
or  several  subtasks  from  several  functional  areas. 

Thus,  this  functional  task  area  strategy  describes  broad, 
achievable  requirements  for  accomplishing  the  relevant  STARS  objec¬ 
tives.  Its  main  purpose  is  to  help  guide  the  implementation  planning 
process. 
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1.0  INTRODUCTION 


1.1  Objective! 

The  overall  objective  of  this  task  area  should  be  to  improve  the 
practice  of  project  management  to  contribute  to  the  goals  of: 

o  shorter  schedules 

o  higher  quality  products 

o  greater  cost  effectiveness 

o  better  forecasting 

o  increased  product  knowledge  transfer. 

The  objective  would  be  accomplished  by  producing  and  making  available 
to  project  managers  tools,  methodologies,  models,  and  training  pro¬ 
gress  designed  to  achieve  the  goals. 

1.2  Background 

Software  system  development  and  support  projects  differ  in  one 
major  respect  from  other  system  projects.  In  most  other  technolo¬ 
gies,  component  development  and  systems  development  are  separate 
functions.  In  these  technologies  systems  are  developed  by  integrat¬ 
ing  and  interfacing  known  components.  This  is  not  usually  the  case 
in  software  systems  In  software  systems  the  components  are  modules. 
In  general  these  modules  are  under  development  concurrently  with  the 
system  development,  so  the  system  designer  is  trying  to  integrete  and 
interface  components  which  are  not  well  understood.  These  uncertain¬ 
ties  cause  software  project  development  to  be  considerably  complex. 
Software  system  designers  usually  specify  the  components  to  support 
the  system  concepts  rather  than  designing  the  system  around  com¬ 
ponents  with  already  fixed  characteristics.  The  usual  result  is  that 
some  software  modules  cannot  be  developed  to  meet  the  specif ications • 
provided  by  the  system  designers.  The  system  designers  must  then 
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alter  the  system  design  which  effects  other  modules  and  their 
development.  The  effect  on  planning,  scheduling,  and  costing  of  this 
kind  of  activity  is  significant.  In  post -delivery  support,  the  plan¬ 
ning  scheduling  and  costing  problems  are  still  severe  because  the 
trade-off's  and  design  decisions  made  during  development,  for  the 
previously  stated  reasons,  result  in  a  product  that  is  not  well 
understood  and  is  many  times  a  collection  of  undocumented  compromises 
to  a  straight  forward  design.  For  these  reasons  the  complexities  of 
software  project  management  require  innovative  tools  and  management 
skil  Is. 

This  task  area  is  concerned  with  issues  relating  to  both  the 
system  buyer  and  the  system  producer  as  well  as  their  interface  both 
with  each  other  and  up  and  down  their  respective  management  chains  as 
illustrated  in  Figure  1-1.  The  Project  Management  Functions  that  are 
objects  of  concern  are  the  planning,  control,  decision  making,  per¬ 
sonnel  management  and  leadership  that  are  necessary  to  control  the 
excecution  of  software  project  life  cycle  functions  within  cost  and 
schedule  constraints.  The  management  fuctions  that  are  the  subject 
of  this  task  area  are  separated  from  acquisition  functions  which  are 
the  subject  of  the  acquisition  task  area  as  shown  in  Figure  1-2. 

People  who  carry  out  the  Project  Management  Functions  are  iden¬ 
tified  by  a  set  of  titles  which  lack  consistency  both  within  the  DoD 
and  within  induatry.  In  addition  the  Project  Management  Functions  are 
generally  performed  by  more  than  one  person  within  the  buyer  and  pro¬ 
ducer  organizations  depending  on  their  individual  organizational 
structures.  People  within  DoD  who  perform  Project  Management  Func¬ 
tions  may  have  titles  which  include:  program  manager,  project 
manager,  project  engineer,  acquisition  manager,  acquisition  engineer, 
department  head,  branch  head,  or  section  head.  People  within  the 

•  ■  4 

producer  organization  may  have  similar  titles,  but  "project  manager" 
is  more  or  less  standard.  For  the  purpose  of  this  plan  the  people 
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FIG.  1-1 


vbo  carry  out  Project  Management  Functions  are  the  Buyer's  manager 
and  the  Producer's  Manager. 

The  Buyer's  Manager  and  Producer's  manager  must  carry  out  mutu¬ 
ally  supportive  Project  Management  Functions  while  receiving  guidance 
and  direction  from  different  superiors,  reporting  to  different  higher 
authority,  and  adhering  to  different  policy,  regulations,  standards, 
schedules,  resource  constraints,  and  motivational  factors.  The  flow 
of  project  information  across  the  buyer /producer  interface  can  be 
strongly  influenced  by  the  differences  in  the  buyer  and  producer 
environments. 

There  are  at  least  four  buyer/producer  relationships  that  must 
be  considered  in  analysing  the  project  management  function.  These 
relationships  are  identified  in  Table  1-1.  The  first  of  these  rela¬ 
tionships  is  characterized  by  the  fact  that  the  contractor  is  respon¬ 
sible  for  the  total  system,  including  the  acquisition  or  development 
of  all  components,  system  integration,  installation,  check-out  and 
functional  demonstration. 

The  second  relationship  is  characterized  by  the  fact  that  some 
aspects  of  system  integration  and  functional  demonstration  are  the 
responsibility  of  the  buyer.  The  third  and  fourth  relationships  are 
characterized  by  the  fact  that  both  buyer  and  producer  are  within  the 
DoD.  The  second,  third  and  fourth  relationships  are  more  typical  of 
the  software  support  (redevelopment)  phase. 

Although  the  Project  Management  Functions  which  must  be  per¬ 
formed  to  accomplish  a  given  project  are  independent  of  the 
buyer /producer  relationship,  the  responsibilities,  authority  and 
granularity  of  management  control  relative  to  specific  phases  of  the 
lifecycle  vary  between  buyer  and  producer,  depending  on  the 
buyer/producer  relationship.  The  capability  of  the  buyer  and  pro¬ 
ducer  manager  to  mutually  support  each  other  is  dependent  on  the 
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buyer/producer  relationships 


TABLE  1-1 


effectiveness  of  the  buyer /producer  interface.  This  task  area  plan 
will  use  the  first  of  the  four  identified  buyer/producer  relation¬ 
ships  as  a  model  for  further  planning  but  will  be  sensitive  to  the 
character  of  all  four  relationships  and  the  effect  that  they  have  on 
Project  Management  Functions. 

1.3  Problem  and  Opportunity  Areas 

Problem  areas  are  the  same  as  the  opportunity  areas  since  each 
problem  presents  an  opportunity  for  its  solution.  Five  typical  prob¬ 
lem  (opportunity)  areas  are  identified  in  this  section. 

1.3.1  Low  Visibility:  Nobody  Knows  What's  Going  On 

Software  is  silent  and  invisible  and  the  development  project 
structure  is  most  often  ad  hoc.  It  is  difficult  for  the  Buyer's 
manager  to  get  answers  to  important  questions  such  as:  Who  is  making 
the  technical  decisions?  Who  reviews  them?  What  are  the  conse¬ 
quences  of  observed  schedule  slippages?  Do  the  decision  makers 
always  have  the  right  information?  Is  the  system  under  development 
going  to  make  its  performance  goals?  Would  more  people  help?  Are  we 
in  trouble?  If  so,  what  corrective  actions  can  be  taken? 

Given  the  poor  reporting  and  ad  hoc  management  structure  of  many 
software  development  projects,  it  is  doubtful  if  anyone  within  the 
project  knows  the  answers  to  these  questions.  It  is  not  because  he 
is  unwilling  that  the  Producer's  manager  does  not  provide  answers,  it 
is  because  he  is  ignorant  of  the  answers. 

1.3.2  Poor  Forecasting:  Nobody  knows  what's  coming  next 

Time  and  cost  overruns  are  common  in  software  projects  and  seem 
to  occur  whether  or  not  an  automated  resource  estimating  (or  cost 
estimating)  tool  is  used.  Models  underlying  the  resource  estimating 
tools  are  poorly  defined  and  often  use  unmesaurable  parameters.  'It* 
is  not  just  that  cost  estimating  tools  are  poor  and  must  be  improved. 
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The  problem  is  Chat  ad  hoc  methods  of  software  design  and  project 
organization  cannot  be  modeled  accurately  and  so  cost  estimating 
tools  are  inappropriate  to  them. 

1.3.3  Inadequate  Product:  Nobody  Knows  If  It  Will  Work 

Two  ways  that  a  product  can  fail  to  "work"  are  1)  failure  to 
meet  the  needs  of  its  users  and  2)  intractability  in  the  face  of 
needed  post -delivery  modifications.  Both  these  types  of  failure  can 
be  attacked  by  project  management  techniques  based  upon  software 
engineering. 

1.3.4  Poor  Organization:  Hobodv  Knows  Who's  In  Charge 

The  term  "adhocracy"  has  been  coined  to  describe  the  cadre  of 
managers  who  arrived  at  their  positions  through  ad  hoc  appointments. 
Very  often  these  ad  hoc  appointments  are  poorly  defined  so  that,  for 
example,  a  Senior  Software  Engineer  may  be  given  "complete  technical 
responsibility"  without  the  budgetary  authority  to  implement  his 
decisions.  In  order  for  project  organization  to  be  effective,  com¬ 
munication  and  control  lines  within  the  project  must  be  explicit  so 
that  guidance  flows  to  the  real  decision  makers. 

1*3.3  People  Problems 

Project  Managers  need  career  development.  One  consequence  of  ad 
hoc  appointments  is  that  managers  are  often  lacking  some  educational 
prerequisite  for  their  jobs.  Software  professionals  lack  basic 
management  skills  and  management  professionals  often  know  little  of 
software  technology.  Within  the  DoD,  software  development  and 
redevelopment  are  often  hanpered  by  ignorance  of  military  applica¬ 
tions  and  doctrine. 

I*4  Strategy 

Automation  of  existing  practices  would  not  be  goal  of  the  Pro¬ 
ject  Management  Rather,  the  goal  should  be  to  investigate  candidate 
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strategies  for  better  project  management  and  improved  organisation, 
and  then  determine  what  automated  tools  and  skills  are  required  to 
support  them.  Too  much  concentration  on  existing  tool  sets  should  be 
avoided,  since  these  tool  sets  may  implicitly  encourage  the  use  of 
outmoded  methodologies.  Methodologies  should  dictate  tool  develop¬ 
ment,  not  the  other  vay  around. 

The  strategy  begins  with  a  functional  analysis  of  project 
activity.  The  results  of  the  analysis  are  embodied  in  a  set  of  Pro¬ 
ject  Models,  which  become  the  driving  force  of  the  strategy.  The 
models  developed  at  the  inception  of  the  task  strategy  are  used  as  a 
unifying  principle  throughout.  At  a  late  stage  in  the  work  these 
models  would  be  automated  and  become  the  integrating  component  of  an 
Advanced  Project  Management  Tool  Set. 

The  strategy  consists  of  three  tasks: 

a*  A  Project  Management  Functional  Analysis 

b.  The  Development  of  Project  Management  Tools  and 

c.  The  Development  of  Management  Skill  Educational  Concepts. 
These  tasks  are  identified  in  Figure  1-3. 


PROJECT  MANAGEMENT  FUNCTIONAL  ANALYSIS 


DEVELOP  MANAGEMENT  SKILLS  EDUCATIONAL  CONCEPTS 


I 


TASKS 


2.1  Proiect  Management  Function*!  Analysis 

The  goal  of  this  task  would  be  to  better  the  understanding  of 
the  project  management  function.  The  approach  is  to  model  projects 
in  a  way  which  provides  a  generic  and  consistent  description  of  pro¬ 
ject  activities  and  their  relation  to  one  another  in  both  sequence 
and  required  coordination.  The  Project  Model  consists  of  two  parts, 
a  set  of  Activity  Elements  and  the  Policies  and  Procedures  which 
define  the  interrelationship  among  the  Activity  Elements.  The  output 
of  the  task  includes  Project  Models  that  can  be  used  by  managers  for 
increased  visability  and  better  reporting.  The  Project  Models  also 
provide  a  basis  for  the  development  of  automated  project  management 
tools. 

The  products  to  be  developed  are  designed  to  lead  to  real  time 
project  management.  Real  time  project  management  means  that  informa¬ 
tion  is  provided  in  a  manner  timely  enough  that  corrective  action  may 
be  taken  in  such  a  way  that  the  overall  schedule  of  the  project  is 
not  affected.  Real  time  project  management  will  benefit  both  the 
buyer  and  the  producer. 

The  objective  of  project  management  is  to  control  the  execution 
of  activities  to  successfully  accomplish  each  phase  of  the  software 
lifecycle.  Within  a  Project  Model  the  Activity  Elements  define  what 
is  to  be  done.  The  Policies  and  Procedures  are  an  expression  of  the 
manager's  plan,  including  project  implementation  methodology, 
sequencing  of  activities,  activity  interfaces,  and  lines  of  control 
and  reporting.  In  this  way  the  Project  Model  describes  what  must  be 
done,  when  it  is  to  be  done  and  how  it  is  to  be  done.  Because  the 
project  management  function  is  to  define  what  is  to  be  done  (activi¬ 
ties),  plan  how  and  when  it  is  to  be  done  (policy  and  procedures), 
monitor  progress  and  redefine  and  replan  as  required,  the  Project 


Model  is  a  useful  way  of  understanding  the  project  management  func¬ 
tion. 

The  two  parts  of  the  Project  Models  (Activity  Elements  and  Poli¬ 
cies  and  Procedures)  must  be  carefully  constructed  in  order  to  avoid 
modeling  ad  hoc  organizations  and  perhaps  institutionalizing  them. 
The  intent  of  project  management  functional  analysis  is  to  build  the 
Project  Models  from  coherent  organizational  structures  based  upon 
software  design  methodologies.  Before  a  generally  applicable  set  of 
Activity  Elements  can  be  constructed,  tvo  tasks  must  be  accomplished. 
They  are  concerned  with  work  breakdown  structures  and  project  docu¬ 
mentation. 

The  set  of  Activity  Elements  in  the  Project  Model  are  to  be 
based  upon  a  generic  (or  at  least  flexible)  work  breakdown  structure. 
However,  producing  the  generic  WBS  could  best  be  done  by  generalizing 
or  abstracting  from  the  individual  WBSb  that  are  implied  by  the  vari¬ 
ous  software  design  methodologies  to  be  studied.  Moreover,  each 
methodology  would  imply  certain  high  level  policies  and  procedures 
(e.g.  "module  decomposition  first"  or  "design  before  code")  that  are 
to  be  associated  with  the  MBS.  The  first  task,  therefore,  would  be 
to  produce  a  set  of  WBS  structures  associated  with  software  design 
methodologies  and  the  high  level  policies  and  procedures  that  would 
be  asaociated  with  them.  The  product  of  this  task  would  chiefly  be 
used  as  input  to  construction  of  the  Project  Models.  However,  it 
would  be  useful  by  itself  since  it  would  provide  project  managers 
with  the  organizational  implications  of  their  decisions  concerning 
software  design. 

Because  software  production  tends  to  be  a  document-driven 
activity,  decisions  on  project  documentation  (including,  but  not  lim¬ 
ited  too,  documents  that  are  delivered  with  the  software)  would  hpve, 
an  influence  on  both  the  WBS  and  on  policies  and  procedures.  A  task 
should  be  established  to  identify  new  and  promising  methods  of 


"design  through  documentation",  to  demonstrate  their  superiority  over 
current  methods ,  and  to  identify  their  impact  on  the  VBS  and  on  poli¬ 
cies  and  procedures.  As  with  the  previous  task,  the  output  of  the 
documentation  task  would  be  chiefly  designed  to  be  input  to  the  Pro¬ 
ject  Models,  but  it  should  also  be  useful  on  its  own. 

2.1.1  The  Activity  Element 

The  Activity  Element  has  been  chosen  as  a  mechanism  for  identi¬ 
fying  the  component  parts  of  a  project  and  the  attributes  of  those 
parts  which  form  the  knowledge  base  upon  which  management  activities 
are  carried  out.  The  purpose  of  this  task  is  to  identify  the  activi¬ 
ties  on  both  sides  of  the  buyer /producer  interface  which  together 
make  up  each  phase  of  the  software  lifecycle  and  to  identify  the 
attributes  of  those  activities  which  can  be  used  to  measure  and  con¬ 
trol  the  project.  The  structure  of  the  Activity  Eleaent  must  be  pro¬ 
ject  independent.  The  structure  consists  of  two  parts,  activity  name 
and  activity  attributes. 

The  following  are  examples: 

a.  Activity  Element  #1 

Mane:  DoD  Planning,  Programming  and  Budgeting. 

Attributes:  1.  Function  of  -  Buyer  Manager 

2.  Schedule  -  2  years  prior  to  budget  year 

3.  Resources  -  0.5  MY /Year 

b.  Activity  Element  #2 

Mate:  Code  Module 

Attributes:  1.  Function  of  -  Programmer  A 

2.  Schedule  -  Test  in  2  weeks 

3.  Resources  -  0.025  MY 

Activity  attribute  values  are  project  specific  although  the  attri¬ 
butes  themselves  are  not.  The  degree  to  which  the  semantics  of  each 
activity  in  the  model  must  be  captured  is  highly  variable.  There¬ 
fore,  an  initial  version  of  the  Activity  Element  can  be  very  simple.. 
As  an  example,  if  management  needs  only  to  know  whether  a  particular 
computer  progra  has  beam  finished,  is  in  progress,  or  hasn't  been 
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•Carted,  then  the  Activity  Element  need  contain  only  those  three 
states,  but  none  of  the  semantics  of  the  activity  "WRITE  COMPUTER 
PROGRAM  XX".  The  element  need  not  know,  for  example,  what  the  pro¬ 
gram  does  or  who  is  writing  it  or  hov  it's  coming  along  or  how  good 
it  is.  On  the  other  hand,  if  management  needs  to  know  how  much  of 
the  activity  has  been  completed  or  the  quality  of  the  work,  then  a 
much  more  detailed  element  would  be  required  which  would  support  the 
processing  needed  to  form  progress  and  quality  estimates. 

A  salient  feature  of  the  Activity  Elements  that  has  been  noted 
are  their  neutrality,  that  is,  their  independence  from  policies,  pro¬ 
cedures,  management  styles,  management  methodologies,  and  design 
technology.  It  is  important  that  each  Activity  Element  be  generic  in 
nature.  This  is  because  experience  has  shown  that  software  tools 
implicitly  require  particular  ways  of  doing  things  and  so  dictate 
methodology  instead  of  the  other  way  around.  Activity  Elements  can  be 
useful  development  tools,  useful  experimental  prototypes,  and 
testbeds  for  methodologies;  all  without  constraining  project  manage¬ 
ment  to  any  particular  style  and  without  making  a  commitment  to  any 
particular  design  philosophy.  Activity  Elements  can  provide  the 
basis  for  a  consistent  structure  (tool)  for  management  data  to  allow 
real-time  transfer  of  knowledge  across  the  buyer/producer  interface. 

2*1*2  Policies  and  Procedures 

Policies  and  Procedures  define  the  sequence  of  project  activi¬ 
ties  and  the  coordination  and  information  trasnfer  which  must  take 
place  between  activities.  Policies  and  Procedures  are  the  relational 
semantics  of  the  Project  Model.  Policies  and  Procedures  are  project 
specific.  They  are  strongly  related  to  software  engineering  concepts 
and  the  design  of  the  product. 


If  the  elements  of  the  Project  Model  are  the  building  blocks  of 
the  project ,  then  the  Policies  and  Procedures,  anong  other  things, 
are  the  ways  of  connecting  them  up.  As  examples,  consider: 

a.  administrative  lines  of  control:  these  are  policies. 

b.  reporting  requirements:  these  are  policies. 

c.  hov  the  monthly  report  is  produced:  this  is  a  procedure. 

d.  "design  before  code":  this  is  a  policy. 

e.  documentation  is  done  on  a  word  processor:  this  is  a  pro¬ 
cedure. 

f.  use  a  particular  design  methodology:  this  is  a  policy. 

g.  programmers  keep  notebooks:  this  is  a  policy. 

Policies  and  Procedures  may  be  thought  of  initially  as  ways  of  con¬ 
necting  and  coordinating  the  elements  of  the  Project  Model  but  this 
is  actually  an  oversimplification.  Policies  and  Procedures  are 
needed  in  order  to  refine  the  attributes  of  the  Activity  Elements. 
This  interplay  between  the  elements  of  the  Project  Model  and  their 
relational  semantics  can  be  seen  most  easily  when  we  consider  the 
influence  of  software  design  methodology  on  project  organization. 

In  the  early  1960s  it  was  often  said  that  software  systems 
resembled  the  organization  charts  of  the  groups  that  produced  them. 
In  more  recent  times  this  relationship  has  reversed  itself  and  pro¬ 
ject  organization  tends  to  mimic  the  modularity  of  the  software 
design.  Thus  if  an  avionics  system  is  to  be  written  and  it  is  deter¬ 
mined  that  the  system  will,  at  the  highest  level,  be  modularized  into 
"weapons"  and  "navigation",  the  project  will  be  organized  into  a 
weapons  section  and  a  navigation  section  with  first-line  managers  for 
each.  The  work  breakdown  structure  (or  its  equivalent)  will  also 
reflect  this  division.  It  is  highly  desirable  that  project  organiza¬ 
tion  be  driven  by  the  modularization  of  the  software  since  a  Module" 


is  a  work  assignment  and  organizing  projects  according  to  work 
assignments  leads  to  an  organization  where  there  is  a  high  degree  of 
compatibility  between  the  administrative  lines  of  control  and  the 
flow  of  work.  However,  just  as  a  poorly  conceived  decomposition  of 
the  system  into  modules  leads  to  a  system  that  is  so  highly  connected 
that  it  is  hard  to  maintain,  the  same  poorly  conceived  modularization 
leads  to  a  project  organization  with  many  crossing  lines  of  control, 
poor  communication  and  weak  administrative  links.  Therefore,  we 
regard  software  design  methodology  as  one  of  the  most  important  of 
the  policies  and  procedures  that  we  will  consider. 

The  purpose  of  the  Policies  and  Procedures  subtask  would  be  to 
identify  project  organizational  success  factors  and  to  integrate  them 
with  the  Activity  Elements.  The  "project  organizational  success  fac¬ 
tors"  are  simply  sets  of  Policies  and  Procedures  that  have  worked 
successfully  in  real  projects  and  have  been  identified  and  described. 

In  addition,  certain  concepts  have  already  been  identified  as 
having  so  much  potential  for  both  achieving  project  success  and 
delivery  of  high  quality  products  that  they  have  separate  Policy  and 
Procedures  associated  with  them.  One  of  these  has  already  been  men¬ 
tioned:  the  influence  of  software  design  methodology  on  project 
organization.  The  others  are  concerned  with  documentation  tech¬ 
niques,  decision  criteria  for  software  module  decomposition,  program 
verification,  software  technology  evaluation,  and  characterization  of 
change.  Each  of  these  factors  embodies  Policies  and  Procedures  that 
drive  the  organization  of  a  project  and  contribute  to  its  success  or 
failure. 

Policies  and  Procedures  are  constrained  by  buyer  and  producer 
organization;  direction  from  superiors,  reporting  requirements  to 
higheT  authority;  buyer  and  producer  corporate  policies,  regulatiops, 
standards,  and  schedules;  resource  constraints,  and  motivational  fac¬ 
tors.  Policies  end  Procedures  define  the  project  organization. 
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documentation  methods,  and  sequence  related  concepts  such  as  design 
before  code. 


2.1.3  Model  Validation 

The  nest  stop  in  understanding  the  project  management  function 
would  be  to  validate  the  modeling  techniques  against  known  software 
engineering  methods  to  see  if  the  Activity  Elements  coupled  with  the 
Policies  and  Procedure  would  provide  a  generic  way  of  defining  the 
project.  There  are  several  questions  to  answer  in  our  validation 
process : 

a.  Is  the  structure  of  the  Activity  Elanents  generic,  i.e. 
independent  of  the  Policies  and  Procedures? 

b.  Can  projects  be  completely  described  by  relating  Activity 
Elanents  to  Policy  and  Procedures? 

c.  Does  the  notion  of  Policy  and  Procedures  work  for  a  number 
of  software  engineering  methodologies? 

Feedback  from  the  exercise  of  the  Initial  Project  Management  Tool 
set,  described  in  section  2.2.1,  can  be  used  to  enrich  the  semantic 
quality  of  the  Project  Model  and  validate  the  concept  based  on  a  lim¬ 
ited  set  of  real-world  projects. 

2.1.4  PtUysriHg? 

o  Project  Structures.  Research  results  on  work  breakdown 
structures  associated  with  software  design  methodologies  and 
the  high-level  policies  and  procedures  that  they  imply. 
Comparison  of  design  methodologies  with  respect  to  work 
breakdown  structure  and  policies  and  procedures.  (Should  be 
delivered  by  FT85.) 

o  Documentation  Structures.  Research  results  on  improved 
documentation  techniques,  their  impact  on  work  breakdown 
structures,  and  their  impact  on  policies  and  procedures.  A 
set  of  model  documentation  would  be  delivered  together  with 
guidelines  for  using  the  techniques.  (Should  be  delivered* 
by  FY86.) 


o  Activity  Elements.  The  Activity  Elements  to  be  delivered 
are  conceptual  but  recommendations  should  be  included  for 
later  automation.  A  format  compatible  with  eventual  imple¬ 
mentation  as  a  knowledge  base  is  required.  (Should  be 
delivered  by  FY86.) 

o  Policies  and  Procedures.  Collected  Policies  and  Procedures 
from  several  design  methodologies  with  recommendations  for 
their  integration  with  the  Activity  Elements.  (Should  be 
delivered  by  FY87.) 

o  Project  Models.  These  conceptual  models  would  be  built  by 
integrating  the  Activity  Elements  with  methodology-specific 
Policies  and  Procedures.  If  necessary,  high-level  policies 
and  procedures  would  be  rewritten  in  order  to  be  at  the 
right  level  of  detail  to  integrate  the  Acitivity  Elements. 
(Should  be  delivered  by  FY87.) 

o  Project  Model  Validation  Plan  and  Results.  The  plan  should 
specify  how  to  test  the  delivered  Project  Models  against 
known  software  engineering  methods  in  order  to  determine  if 
the  Project  Models  provide  a  generic  way  of  defining  and 
modeling  projects.  The  Results  of  Validation  would  contain 
recommendations  concerning  automation  of  one  or  more  Project 
Models  to  form  the  Project  Activity  Coordinator  of  the 
Advanced  Project  Management  Tool  Set.  (Should  be  delivered 
by  FY88.) 

2.2  Project  Management  Tool  Set 

2.2.1  Initial  Project  Management  Tool  Set 

The  first  step  in  the  development  of  project  management  tools 
would  be  the  acquisition  and  exercise  of  one  or  more  Initial  Project 
Management  Tool  Sets.  The  tools  for  this  initial  tool  set  would  be  in 
the  main  off-the-shelf  tools  with  a  primary  objective  of  the  acquisi¬ 
tion  being  to  establish  among  the  set  of  tools  a  common  data  base  for 
interfacing  the  activities  (input /output )  associated  with  each  tool. 


The  acquisition  should  consist  of  two  phases.  First  the  evaluation 

and  selection  of  candidate  tools  and  second  the  system  design  and 

*  • 

software  effort  to  integrate  and  interface  the  tools.  The  second 
part  of  the  Initial  Project  Management  Tool  Set  effort  is  the  exer- 


cise  of  the  tool  sets  on  real  DoD  software  acquisitions.  The  Initial 
Project  Management  Tool  Set  would  not  only  provide  a  set  of  useful 
tools  for  today's  manager,  using  today's  methods,  but  would  also  pro¬ 
vide  a  means  for  identifying  opportunities  for  improving  management 
methods  and  more  powerful  tools. 

There  are  two  critical  aspects  of  the  Initial  Project  Management 
Tool  Set  effort.  The  first  is  that  the  tool  set  must  be  common  to 
both  the  buyer  and  producer,  must  be  integrated  with  the  development 
environment  and  be  supported  with  a  robust  buyer/producer  interface. 
The  second  is  that  the  use  of  the  tool  set  must  capture  significant 
knowledge  about  the  influence  of  tools  on  management,  the  signifi¬ 
cance  of  information  flow^  and  the  shortcomings  of  off-the-shelf 

tools.. 

• 

The  Initial  Project  Management  Tool  Set  represents  a  unique 
opportunity  to  capture  knowledge  of  the  management  process  of  a  real 
project.  In  order  to  enhance  this  capture  a  requirement  of  the  Ini¬ 
tial  Project  Management  Tool  Set  should  be  that  the  tool  set  must 
provide  the  capability  for  generating  and  maintaining  a  time  tagged 
data  base  (audit  trail)  of  tool  activity.  The  knowledge  of  the 
management  process  gained  through  use  of  the  Initial  Project  Manage¬ 
ment  Tool  Set  would  support  the  validation  of  the  results  of  task 
2.1. 

2. 2. 1.1  Users  Group.  A  users  group  would  be  formed  to  support 
the  DoD  component  responsible  for  managing  the  Initial  Project 
Management  Tool  Set  effort.  The  users  group  should  be  constituted  of 
senior  project  managers  from  DoD  and  industry  who  are  experienced  in 
both  software  development  and  support.  The  users  group  would  provide 
guidance  on  refining  the  requirements  for  the  Initial  Project 
Management  Tool  Set.  This  activity  would  include:  identifying  jthe, 
types  of  tools,  such  as  those  identified  in  Table  2-1,  which  should 
form  the  basis  of  the  Initial  Project  Management  Tool  Set,  defining 


Functional  Capability 


Summary  Description 


Data  Base  Management 

Word  Processing 

Word  Pack 

Te lec ommun i c a t i on 

Graphics 

Electronic  Worksheet 
Interactive  Work  Planning 
Schedule  Generation 

Cost  Estimation 
Margin  Management 

Manpower  Ranking  and  Rating 

Management  Information 
Reporting 

Configuration  Management 

Help 

Tutorial 


Relational  data  manager  with 
query  features 

Executive  word  processor 
with  limited  sophistication 

Spelling  and  grammar  checkers 

Processor  to  processor  com¬ 
munications  and  electronic 
stail 

Business  graphics  generation 
and  editor 

Business  spreadsheet 
calculator 

Work  Breakdown  Structuring 
(WBS)  generator  and  tracker 

Bar  and  Gantt  chart 
generation  and  editor 

Quick-and-dirty  cost 
estimator 

Margin  (memory,  speed  and 
input/output  variances 
between  actuals  and  goals) 
tracker 

Personnel  ladder  ranking  and 
rating  worksheets 

User  defined  and  precanned 
report  generators 

On-line  problem  reporting 
and  change  status  accounting 
system 

Structured  help  generator 

Pre-established  examples  ' 
used  as  learning  aids 


Table  2-1 

INITIAL  PROJECT  MANAGEMENT  TOOL  SET 
CANDIDATE  TOOLS 
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requirements  for  the  tool  set  user  interface ,  defining  requirements 
for  a  common  tool  set  data  base  and  defining  requirements  for  an  Ini¬ 
tial  Project  Management  Tool  Set  audit  trail.  The  users  group  would 
provide  guidance  for  defining  learning  objectives  for  the  exercise  of 
the  Initial  Project  Management  Tool  Set.  The  users  group  would  be  a 
continuous  function  within  the  Project  Management  Tool  Set  effort. 
The  group  would  support  the  source  selection  process  with  regard  to 
the  contractor  developed  Initial  Project  Management  Tool  Set  and 
would  review  and  comment  on  Initial  Project  Management  Tool  Set 
design  documents,  test  and  evaluation  plans,  and  reports  and  exercise 
plans. 

2. 2. 1.2  Acquisition  Strategy.  Criteria  to  considered  with 
regard  to  acquiring  the  Initial  Project  Management  Tool  Set  are:  the 
availability  of  off-the-shelf  tools,  the  availability  of  an 
integrated  software  development  environment,  and  a  minimal  impedance 
buyer /producer  interface.  Alternative  acquisition  strategies  muBt  be 
weighed  against  these  criteria.  Three  approaches  are  identified: 


a.  Build  on  Automated  Project  Management  tools  in  development 
by  DoD  components  such  as  the  Facility  for  Automated 
Software  Production  (FASP)  work  at  the  Naval  Air  Development 
Center  and  the  Graphical  Interactive  Technique  for  Project 
Analysis,  Scheduling  and  Evaluation  (GITPASE)  work  at  the 
Army  Institute  for  Research  in  Management  Information  and 
Computer  Sciences  (AIRMICS).  Exercise  the  resulting  Initial 
Project  Management  Tool  Set  to  manage  a  software  development 
or  support  (redevelopment)  effort  within  DoD,  where  both  the 
buyer  and  producer  are  within  DoD,  to  minimize 
buyer /producer  interface  problems. 


b.  Issue  an  RFP  to  competitively  procure  one  or  more  Initial 
Project  Management  Tool  Sets.  Specify  the  use  of  the  pro¬ 
cured  tool  set  as  GFE  on  a  contract  for  software  develop¬ 
ment. 


c.  Add  the  requirement  for  developing  and  using  an  Initial  P^o-. 
ject  Management  Tool  Set  by  the  contractor  and  DoD  manager 
to  the  RFP  for  a  competitive  procurement  of  a  software 
intensive,  mission  critical  system. 


Based  on  an  evaluation  of  the  alternatives,  the  strategy  for 
obtaining  the  Initial  Project  Managonent  Tool  Set  is  bidirectional. 
Two  Initial  Project  Management  Tool  Set  efforts  should  be  undertaken. 
One  effort  would  be  directed  toward  an  acquisition  environment  where 
both  buyer  and  producer  are  within  the  DoD.  The  other  effort  would 
be  directed  toward  an  enviornment  where  the  buyer  is  a  DoD  component 
and  the  producer  is  a  contractor.  Alternative  (a)  should  be  used  for 
the  first  effort  to  develop  a  tool  set  which  would  identify  DoD  pro¬ 
jects  already  in  progress.  On  of  these  projects  would  be  chosen  to 
be  expanded  to  meet  Initial  Project  Management  Tool  Set  requirements 
identified  by  the  user  group  and  interfaced  with  an  internal  DoD 
software  development  effort.  The  key  to  this  interface  is  the  iden¬ 
tification  of  a  DoD  organic  software  project  which  makes  use  of  an 
integrated  software  development  environment.  An  integrated  environ¬ 
ment  would  reduce  the  tool  set  interface  effort.  Because  both  buyer 
and  producer  are  within  DoD,  problems  of  proprietary  or  private  data 
should  not  exist  and  the  necessary  real  time  free  flow  of  data  input 
to  the  tools  should  be  realizable.  The  second  effort  would  use 
alternative  (c)  and  would  be  intended  to  leverage  industrial  efforts. 
Again  one  of  the  key  elements  in  choosing  alternative  (c)  is  the  need 
for  the  tools  to  have  an  effective  interface  with  development  data. 
The  requirements  for  the  Initial  Project  Management  Tool  Set  identi¬ 
fied  by  the  user  group  should  be  added  to  the  development  statement 
of  work  and  specifications.  Software  Initiative  funds  should  be 
added  to  the  funds  available  for  the  candidate  systems  development  to 
offset  the  cost  of  the  contractors  efforts  to  integrate  the  tools  and 
deliver  the  Initial  Project  Management  Tool  Set  to  the  DoD  project 
manager.  Innovative  acquisition  practices  must  be  employed  to  pro¬ 
vide  proprietary  tools  and  private  data  for  unrestricted  DoD  use 
while  protecting  industrial  proprietary  rights.  In  addition,  the 
system  development  award  must  be  made  on  a  competitive  basis  and 
careful  attention  paid  to  the  selection  process  to  ensure  the 
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•election  of  a  contractor  who  can  meet  the  Initial  Project  Management 
Tool  Set  requirements  with  already  existing  internally  developed 
tools.  It  is  critical  that  the  contractor  be  able  to  deliver  to  the 
DoD  manager  a  set  of  tools  early  in  the  contract  and  be  willing  to 
share  development  data  in  real  time. 

2. 2. 1.3  Initial  Proiect  Management  Tool  Set  Exercise.  Each  of 
the  two  Initial  Project  Management  Tool  Set  efforts  must  have  an 
exercise  plan  and  procedures  which  identify  what  is  to  be  learned 
from  use  of  the  Initial  Project  Management  Tool  Set  and  how  this 
knowledge  is  to  be  captured.  The  users  group  should  help  define  the 
learning  objectives  and  review  the  exercise  plan  and  procedures.  The 
Initial  Project  Management  Tool  Set  exercise  should  take  place  over 
the  life  of  the  development  or  redevelopment  effort.  Interim  reports 
would  be  generated  to  reflect  experience  gained  and  lessons  learned 
about  the  tools  and  their  interface  withthe  development  support 
activity. 

2.2.1.4  Deliverable?. 

o  Initial  Project  Management  Tool  Set:  Industry.  (Should  be 

delivered  by  FY84.) 

o  Initial  Project  Management  Tool  Set:  DOD.  (Should  be 

delivered  by  FT85.) 

o  Initial  Project  Management  Tool  Set  Exercise  Plan  (Should  be 
delivered  by  F784.) 

o  Initial  Project  Management  Tool  Set  Exercise  Results  (Should 
be  delivered  semi-annually  FY85-FY86 . ) 

2.2.2  Advanced  Proiect  Management  Tool  Set 

The  concepts  and  requirements  for  an  Advanced  Project  Management 
Tool  Set  are  generated  by  the  Project  Management  Functional  Analysis 
Task  2.1  and  the  exercise  of  the  Initial  Project  Management  Tool  Set.' 
The  Project  Model  which  results  from  task  2.1  identifies  project 
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activities  and  the  information  required  to  uniquely  define  the 
activity  and  its  status.  The  Activity  Elements  define  a  knowledge 
base  of  project  activity.  Task  2.1  further  defines  the  Policies  and 
Procedures  required  to  relate  project  activities.  These  Policies  and 
Procedures  are  the  Project  Model  relational  semantics  and  would 
define  the  information  flow  and  the  types  of  coordination  required 
and/or  presecribed  among  the  activities.  The  exercise  of  the  Initial 
Project  Management  Tool  Set  would  provide  insight  into  issues  such 
as : 

a.  timeliness  of  information  flow  across  the  buyer/producer 
interface ; 

b.  perishability  of  status  information; 

c.  interoperability  of  existing  tools; 

d.  availability  of  information;  and 

a.  usability  of  tools. 

The  results  of  tasks  2.1  and  2.2.1  would  constitute  the  basis  for 
developing  advanced  tools  which  would  be  integrated  with  the  best  of 
the  Initial  Project  Management  Tool  Set  tools  to  iteratively  develop 
an  Advanced  Project  Management  Tool  Set. 

2. 2. 2.1  Automated  Tracking  Tools.  The  first  level  of  advanced 
tools  for  integration  into  the  Advanced  Project  Management  Tool  Set 
would  be  the  tools  for  automating  the  tracking  of  product  status. 
These  tools  would  use  the  Activity  Elements  as  a  mechanism  for 
reporting  status.  Status  information  relative  to  activities  related 
to  design,  coding,  configuration,  and  testing  could  be  obtained 
directly  from  an  integrated  prograsming  support  environment  such  as 
an  APSE.  For  the  near  and  mid  term  the  status  of  activities  related 
to  buyer  functions  and  producer  management  functions  might  require 
manual  entry.  The  tracking  tools  would  have  a  common  reporting 
mechanism  across  the  buyer /producer  interface  which  would  be  the 


Activity  Elements  even  thought  in  the  real  world,  some  attributes 
content  may  remain  the  unique  purview  of  either  the  buyer  or  pro¬ 
ducer.  Critical  to  this  first  level  of  advanced  tools  would  be  the 
eompletness  of  the  set  of  Activity  Elements. 

2. 2. 2. 2  Automated  Indication  and  Warning  Tools.  Automated 

Indication  and  Warning  Tools  should  be  built  on  top  of  the  Automated 

Tracking  Tools.  To  support  Automated  Indication  and  Warning  Tools  a 
set  of  parameters  which  bound  expected  or  planned  levels  must  be 
developed  for  each  of  the  Activity  Elements.  These  parameters  would 
be  project  dependent  and  derived  from  the  management  policies  and 

procedures.  Management  judgment  is  a  key  factor  in  setting  the 

parameters.  The  Automated  Indication  and  Warning  Tools  mechanism 
would  be  to  continuously  compare  activity  status  (in  real-time  where 
atatua  reporting  is  automated  such  as  within  an  APSE)  against  pre-set 
activity  parameters.  It  would  alert  the  project  manager  when 
activity  levels  (such  as  time  to  complete)  exceed  the  parameters. 
The  Automated  Indication  and  Warning  Tools  should  alert  the  project 
manager  that  activity  sieaaures  are  out  of  expected  bounds.  These 
warnings  could  materially  enhance  project  managers'  effectiveness 
because  they  would  concentrate  management  activity  on  issues  that 
require  attention.  Activity  paraseters  could  be  established  for  all 
attributes  of  project  activity  such  as: 

a.  time  to  complete 

1.  design 

2.  code 

3.  test 

b.  module  size 

c.  number  of  source  code  change 


* 


d.  level  of  code  annotation 

e.  computer  time  used 

f.  men  hours  used 

g.  available  funds 

Psrameters  could  also  be  established  which  would  provide  warning  of 
policy  violations  such  as  code  being  compiled  before  design  approval. 

2. 2. 2. 3  Automated  Deci«ion_  Support  Tools.  The  Policies  and 
Procedures  defined  by  task  2.1  would  provide  a  framework  for 
Automated  Decision  Support  Tools.  Two  levels  of  decisions  could  be 
defined*  those  which  could  be  made  within  the  confines  of  the  esta¬ 
blished  project  policies  and  procedures  and  those  which  would  require 
changes  to  established  policies  and  procedures.  Concepts  for  imple¬ 
menting  Automated  Decision  Support  Tools  which  support  the  first 
level  of  decision  could  be  developed  for  mid  term  implementation. 
The  Automated  Indication  and  Warning  Tools  parameters  which  relate 
intra-activity  status  to  policies  and  procedures*  such  as  "design 
before  code"  or  ^nodule  n  must  complete  unit  test  before  integration 
testing  of  build  A  can  begin*"  form  a  basis  for  decision  support 
tools  of  the  "what  if"  nature  which  could  support  project  management 
review  of  options  when  alerted  by  the  Automated  Indication  and  Warn¬ 
ing  Tools. 

2.2. 2. 4  Project  Activity  Coordinator.  In  order  for  the 
Advanced  Project  Management  Tool  Set  to  be  most  effective*  some  form 
of  global  communications  and  coordination  interface  must  exist  among 
all  project  participants.  One  part  of  this  interface  would  exist  in 
the  Activity  Elements.  The  Activity  Elements  would  provide  a  cen¬ 
tralized,  consistent  expression  of  activity  knowledge  and  need  to  be 
stored  and  maintained  in  an  automated  environment.  The  second  p*rt , 
of  the  interface  would  be  an  expression  of  the  project  activities' 
relational  semantics.  A  language  for  stating  such  relational 
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semantics  and  an  interpreter  for  this  language  must  be  created.  The 
Activity  Elements  and  their  Relational  Sauantics  Language  would  form 
a  Project  Activity  Coordinator.  Through  the  Project  Activity  Coordi¬ 
nator*  management  activity  could  be  expressed  by  updates  to  the 
Activity  Elements  which  would  record  the  overall  state  of  the  pro¬ 
ject. 

2. 2.2. 5  Advanced  Project  Management  Tool  Set.  The  implementa¬ 
tion  concept  of  the  Advanced  Project  Management  Tool  Set  is  to 
develop  prototypes  of  each  previously  described  tool*  add  the  proto¬ 
type  to  the  baseline  tool  set  resulting  from  the  Initial  Project 
Management  Tool  Set  and  evaluate  the  new  prototype  set.  The  product 
of  this  task  would  be  a  prototype  Advanced  Project  Management  Tool 
Set.  Its  purpose  would  be  to  demonstrate  and  evaluate  tool  concepts 
and  their  use.  The  tool  documentation  would  allow  both  industrial 
and  DOD  managers  to  tailor  and  implement  the  tools  for  their  own 
environments.  The  prototype  tools  would  be  integrated  into  the  DOD 
model  environments  and  supported  by  the  Software  Engineering  Insti¬ 
tute. 

The  Automated  Tracking  Tools*  Automated  Indication  and  Warning 
Tools,  and  Automated  Decision  Support  Tools  are  a  natural  progression 
of  tool  complexity  and  the  strategy  should  be  to  implement  them  in 
that  order.  The  Automated  Tracking  Tool  is  based  on  Activity  Ele¬ 
ments  which  reflect  project  status.  The  Automated  Indication  and 
Warning  Tool  requires  the  capability  of  the  Automated  Tracking  Tool 
and  a  richer  model  which  reflects  additional  knowledge  about  project 
activities  such  as  size  and  quality.  The  Automated  Decision  Support 
Tool  requires  the  capability  of  the  Automated  Indication  and  Warning 
Tool.  The  Automated  Tracking  Tools,  Automated  Indication  and  Warning 
Tools*  and  Automated  Decision  Support  Tools  would  be  prototyped  in 
turn  and  integrated  with  tools  from  the  Initial  Project  Management* 
Tool  Set  which  have  been  proved  useful  by  real  experience.  The  tool 
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set  which  results  from  the  addition  of  each  prototype  must  be  exer¬ 
cised  on  reel  projects  to  judge  its  efficacy.  This  exercise  task  is 
a  continuation  of  the  Initial  Project  Management  Tool  Set  exercise 
specified  in  2.2. 1.4.  In  each  instance  careful  planning  must  be  done 
to  ensure  that  the  results  of  using  the  tools  are  rigorously  captured 
and  that  the  buyer/producer  interface  is  sufficiently  robust  to  sup¬ 
port  the  tools. 

The  Project  Activity  Coordinator  must  evolve  from  an  increas¬ 
ingly  rich  knowledge  base  of  project  activity  and  the  development  of 
a  Relational  Semantics  Language.  The  Project  Activity  Coordinator 
should  be  the  final  step  in  obtaining  the  Advanced  Project  Management 
Tool  Set  because  the  Project  Activity  Coordinator  provides  a  con¬ 
sistent  mechanism  for  communicating  management  and  project  activity 
among  all  participants.  The  Project  Activity  Coordinator  would  not 
be  dependent  on  a  particular  buyer/producer  relationship  nor  would  it 
be  dependent  on  a  particular  set  of  policies  or  procedures  or  activi¬ 
ties.  The  Project  Activity  Coordinator  could  therefore  provide  the 
means  for  the  Advanced  Project  Management  Tool  Set  to  be  project 
independent . 

2.2. 2. 6  Deliverables. 

o  Automated  Tracking  Tool  Prototype,  including  documentation. 
(Should  be  delivered  by  F787.) 

o  Automated  Indication  and  Warning  Tool  Prototype,  including 
documentation.  (Should  be  delivered  by  FY88.) 

o  Automated  Decision  Support  Tool  Prototype,  including  docu¬ 
mentation.  (Should  be  delivered  by  FY89.) 

o  Project  Activity  Coordinator  Prototype,  including  documenta¬ 
tion.  (Should  be  delivered  by  FT89.) 

o  Integrated  Advanced  Project  Management  Tool  Set  Prototype,, 
including  documentation,  guidelines  for  use,  and  courseware. 
(Should  be  delivered  by  FT89.) 


o  Evaluation  and  Test  Results.  (Should  be  delivered  semi¬ 
annually  FY88-FY89.) 

2.3  Development  of  Management  Skill  Educational  Concents 

Managers  of  software  on  both  the  buyer  and  producer  side  tend  to 
be  either  software  professionals  learning  management  skills  on-the- 
job  or  professional  managers  with  relatively  little  experience  in 
software.  Each  needs  to  learn  some  of  the  skills  of  the  other. 
Moreover,  both  need  to  be  made  aware  of  common  pitfalls  inherent  in 
their  position:  the  manager  with  software  experience  tends  to  become 
too  much  involved  in  technical  details  while  the  professional 
manager,  ignorant  of  software,  tends  to  manage  the  Work  Breakdown 
Structure  instead  of  the  project.  This  section  details  four  subtasks 
designed  to  improve  management  skills. 

2.3.1  Management  Job  Descriptions 

In  order  to  properly  develop  an  educational  program  for  project 
management  personnel,  it  is  necessary  to  determine  exactly  what  is 
required  of  them.  This  subtask  calls  for  the  writing  of  a  set  of  job 
descriptions  for  people  involved  in  project  management  on  both  the 
buyer's  and  producer's  side.  A  conjecture  is  that  writing  the 
description  for  the  buyer's  side  will  prove  more  difficult  since  the 
buyer's  environment  is  extremely  diverse  and  may  require  wider 
knowledge,  .  for  example,  of  application  areas  and  authoritative 
sources  of  information.  This  exercise  would  document  the  knowledge, 
skills,  and  abilities  required  for  project  management  and  an  explicit 
description  of  duties.  The  product  of  this  subtask  could  be  used  to 
identify  further  educational  opportunities,  provide  models  for  writ¬ 
ing  government  Position  Descriptions,  and  furnish  criteria  for  con¬ 
tractor  project  managers  during  source  selection. 
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One  difference  between  software  engineering  and  programing  is 
that  software  engineering  involves  many  pro grans,  many  programmers, 
and  the  necessity  to  integrate  them.  This  difference  correctly 
implies  that  software  engineering  has  a  management  component.  This 
subtask  proposes  definition  of  an  educational  program  to  teach  those 
aspects  of  software  engineering  needed  for  management.  Emphasis 
would  be  on  policies  and  procedures  that  support  good  software 
engineering  principles,  the  influence  of  software  design  methodology 
on  project  organization,  and  methodology  for  reviewing  software 
design  documentation. 

2.3.3  Project  Accounting  and  Control 

This  subtask  calls  for  development  of  a  short  educational  pro¬ 
gram  aimed  at  the  software  professional  new  to  management.  The  pro- 
gran  covers  elementary  management  techniques  such  as  work  breakdown 
structures,  planning  and  budgeting,  formal  accounting  systems,  and 
reporting  procedures  derived  from  these  techniques. 

2.3.4  QTRanjUet.iqP*  1.  An»  lijit 

This  task  calls  for  investigation  into  and  documentation  of  the 
various  organizational  strategies  available  to  project  managers 
within  the  constraints  imposed  by  software  design  methodology.  Dif¬ 
ferent  organizational  structures,  such  as  Chief  Programmer  Teams  or 
Adversary  Test  Teams  can  have  a  profound  effect  on  project  management 
and  the  software  product.  For  the  development  manager  who  might  be 
constrained  by  corporate  policy  there  may  appear  to  be  very  little 
scope  for  altering  project  organization.  Tet,  the  project  manager 
can  tailor  organizations  so  as  to  reinforce  certain  policies  and  pro¬ 
cedures,  if  options  are  identified  for  him  and  he  is  properly  edu¬ 
cated.  The  results  of  this  task  will  therefore  be  directed  towards 
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assessing  the  implications  of  organizational  decisions  on  cost,  pro¬ 
ductivity,  and  quality. 


This  subtask  calls  for  the  development  of  a  computer-based  gam¬ 
ing  system  to  provide  exercise  in  project  management  planning  and 
decision  making.  Such  a  gaming  simulator  would  build  on  successes 
that  have  been  recorded  for  this  technology  to  cultivate  judgment 
using  exercises  of  real-world  project  senarios.  Improved  planning 
and  decision-making  skills  could  be  expected  to  result  as  managers 
learn  to  manage  in  a  controlled  learning  situation. 


2.3.6 


o  Management  Job  Descriptions.  (Should  be  delivered  by  FY84.) 

o  Software  Engineering  Principles  Course  Outline  and  Teaching 
Plan.  (Should  be  delivered  by  FY85.) 

o  Project  Accounting  and  Control  Course  Outline  and  Teaching 
Plan.  (Should  be  delivered  by  F786.) 

o  Organizational  Analysis  Report  and  Recommendations.  (Should 
be  delivered  by  PY87.) 

o  Management  Gaming  System.  (Should  be  delivered  by  FT87.) 
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3.0  INTERFACES 


This  task  area  strategy  has  identified  those  tasks  necessary  to 
carry  out  project  management  objectives.  The  strategy  has  concen¬ 
trated  on  activities  which  fall  uniquely  within  the  area  of  project 
management,  realizing  that  those  activities  must  both  be  supported  by 
and  be  supportive  of  activities  within  other  task  areas.  The  follow¬ 
ing  sections  identify  interfaces  with  other  task  areas  that  would 
provide  mutual  support.  These  sections  will  identify  input  in  the 
form  of  requirements  or  products  from  the  Project  Management  Task 
Area  to  other  task  areas  and  the  output  in  the  form  of  methods, 
mechanisms  or  services  which  support  the  Project  Management  Task 
Area. 

3.1  Measurement 

The  Project  Management  Tool  Set  task  would  rely  heavily  on  meas¬ 
urement  tools  as  a  basis  for  the  decision  support  and  indication  and 
warning  tools  which  form  a  part  of  the  Project  Management  Tool  Set. 
The  measurement  area  would  also  support  an  evaluation  of  Project 
Models  and  tools  which  would  result  from  the  individual  tasks.  Table 
3-1  identifies  the  Measurement  Task  Area  interfaces. 

3.2  Support  Systems 

A  critical  element  of  the  Project  Management  Tool  Set  would  be 
its  interface  with  an  integrated  software  support  environment.  The 
requirement  for  consistent  data  within  the  entire  project  environment 
would  be  the  key  to  successful  management  and  a  robust  transfer  of 
knowledge  about  the  project  between  the  buyer  and  producer  organiza¬ 
tions  and  between  successive  phases  of  the  project  lifecycle. 
Activities  of  the  Support  Systems  Task  Area  should  be  the  primary 
focus  for  creating  an  integrated  data  base  which  contains  knowledge 
of  project  activities.  Table  3-2  identifies  the  Support  Systems  Task 
Area  interfaces. 
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INPUT 


OUTPUT 


Measurement  Requirements 
Information  Requirements 


Metrics 

•  Tool  Evaluation 

•  Productivity  Evaluation 

•  Quality  Evaluation 

•  Process  &  Product  Evaluation 

•  Decision  Effectiveness 
Evaluation 

•  Progress  (cost,  schedule  & 
technical  performance 

re lationships) 

•  Cost  Effectiveness 

•  Personnel  Effectiveness 
Information  to  Validate  Models 
&  Metrics 

Measurement  Methods,  Tools, 
Support  and  Training 


Table  3-1 

MEASUREMENT  INTERFACES 


INPUT 


OUTPUT 


Information  Requirements 
(what  data  when  and  how 
much) 

Feedback  from  Initial 
Project  Management  Tool  Set 
Usage  on  Pilot  Projects 

Management  Methods, 
Standards  and  Tools 


Data  Base  Integration 
Methodology 

Tool  Integration  Methodology 
Minimum  Set  of  Tool  Standards 
Data  Standards 
Knowledge  Base 


Table  3-2 
SUPPORT  SYSTEMS 
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3.3  Acquisition 


A  robust  flow  of  information  across  the  buyer/producer  interface 
has  been  identified  as  a  central  issue  with  regard  to  successful  pro¬ 
ject  management.  A  free  flow  of  information  across  the  interface  is 
often  inhibited  or  not  .supported  by  contractual  relationships.  If 
DoD  is  going  to  successfully  leverage  initiative  funds  by  seeding 
Project  -Management  Tool  Set  efforts  within  industry,  then  ways  must 
be  found  to  make  wide  use  of  the  results  of  those  efforts  within  the 
DoD  community.  This  concept  extends  to  being  able  to  specify  the 
best  of  industry  technology  on  competitive  acquisitions.  In  order  to 
make  these  concepts  viable,  acquisition  practice  must  change.  The 
Acquisition  Task  Area  should  be  responsible  for  identifying  impedi¬ 
ments  to  these  concepts  and  recommending  changes  to  contractual  pol¬ 
icy  and  regulation  to  remove  the  impediments.  Table  3-3  identifies 
the  Acquisition  Task  Area  interfaces. 

INPUT  OUTPUT 


o  Data  Exchange  Requirements 

o  Management  Methods , 
Standards  and  Tools 


o  Ways  to  acquire  technology 
for  Gov't  use  £.  write 
provisions  to  protect 
commercial  interests 

o  Innovative  acquisition 
policies  to  induce  the  use 
of  advanced  project 
management  methods  and  tools 

o  Contractual  mechanisms  for 
reducing  cost  and  schedule 
risk  throughout  the 
contracts  term 


o  Data  Exchange  Agreement 

between  buyer  and  producer.  / . 

Table  3-3 
ACQUISITION 
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In  the  long  term,  the  Project  Management  Tool  Set  shall  consist 
of  an  activity  coordinator  which  acts  as  the  central  communications 
interface  among  project  members.  This  interface  is  expressed  in 
terms  of  Activity  Elements  which  are  intended  to  be  so  complete  that 
in  combination  they  record  the  overall  state  of  the  project.  In 
order  to  realize  this  concept  the  Systems  Task  Area  must  provide  such 
tools  as  very  high  level  languages,  knowledge  base  techniques  and 
artificial  intelligence  concepts.  Table  3-4  identifies  the  System 
Task  Area  interfaces. 

3.5  Human  Resources 

Policies  and  Procedures  to  govern  the  software  lifecycle  are 
very  closely  related  to  software  engineering  concepts  and  have  a 
material  effect  on  the  resulting  product.  This  is  in  fact  the 
management  component  of  software  engineering.  Managers  also  must  be 
educated  to  make  real-time  decisions  which  are  both  technical  and 
administrative.  Providing  curricula  to  support  these  educational 
requirements  should  be  the  responsibility  of  the  Human  Resources  Task 
Area.  Table  3-5  identifies  the  Human  Resources  Task  Area  interfaces. 

3.6  Human  Engineering 


In  order  to  provide  usable  and  effective  tools  the  Project 
Management  Tool  Set  development  requires  a  strong  input  from  the 
Human  Engineering  Task  Area  to  ensure  that  the  tools  are  user 
friendly  and  supportive  of  the  manager.  Table  3-6  identifies  the 
Human  Engineering  Task  Area  interfaces. 


Management  Methods, 
Standards  and  Tools 


Expert  System  Technology  and 
Tools 


Advanced  Project 
Management  Tool 
Set  Concepts 

Decision  Support  Concepts 

Table  3-4 
SYSTEMS 


INPUT 


OUTPUT 


Management  Related  .  Better  Educated  Managers 

Component  of  Software 

Engineering 

Requirements  for  Decision 
Making  Skills 

On  Line  Manager  Exercise 
Tools 

Management  Job  Descriptions 

Table  3-5 
HUMAN  RESOURCES 


INPUT 

Manager /Machine  Functional 
Interface  Description 

Feedback  from  Initial 
Project  Management  Tool  Set 

Management  Methods, 
Standards  and  Tools 


OUTPUT 

Manager /Machine  Tool 
Interface  Requirements 
Specifications 


Table  3-6 
HUMAN  ENGINEERING 


4.0  SUMMARY 


4.1  Accomplishments 

The  tasks  described  in  this  task  area  strategy  have  been 
designed  to  improve  the  capability  of  the  project  manager  to  deal 
with  the  problems  discussed  in  section  1.3  by  developing  methods  to 
identify  and  relate  project  activities  so  that  they  support  available 
software  engineering  concepts,  developing  tools  to  aid  the  manager  in 
focusing  his  time  and  resources,  and  providing  educational  material 
and  concepts  to  support  project  manager  education. 

4.1.1  Improved  Visibility 

Tasks  have  been  described  which  provide  a  consist ant  mechanism 
for  understanding  project  activities  and  their  interrelationships. 
This  mechanism  would  provide  for  the  organization  of  project  activi¬ 
ties  and  the  transfer  of  knowledge  about  those  activities  throughout 
the  project  teas  on  both  sides  of  the  buyer  producer  interface. 
Tools  are  defined  which  would  aid  the  project  manager  in  tracking 
project  status,  identifying  potential  problems  and  answering  ques¬ 
tions  relating  to  management  options  within  the  scope  of  establish 
policy  and  procedures. 

4.1.2  Improved  Forcasting 

The  increased  understanding  of  project  activities  and  their 
interrelationships  and  the  ability  to  more  effectively  plan,  organ¬ 
ize,  track  progress,  identify  trouble  spots,  and  perform  conditional 
analysis  of  options  would  improve  forecasting  both  prior  to  and  dur¬ 
ing  project  implementation.  Of  special  importance  would  be  the  abil¬ 
ity  to  make  more  accurate  estimates  of  cost  to  complete. 


4.1.3  Improved  Product 


The  Ability  to  tailor  project  activities,  policy  and  procedures 
to  reinforce  good  softvare  engineering  practice  should  provide  for 
improved  products.  Advanced  tools  would  provide  the  ability  to  iden¬ 
tify  and  solve  problems  in  real-time  so  that  product  quality  and 
schedule  can  be  maintained.  Enhanced  knowledge  about  the  product  and 
the  activities  which  resulted  in  that  product  would  increase  the 
ability  of  software  support  organizations  to  make  effective  changes. 

4.1.4  Improved  Organizations 

The  methods  and  supporting  tools  developed  within  the  scope  of 
this  task  area  provide  a  mechanism  for  tailoring  organizations  and 
supporting  information  flows  as  well  as  the  means  for  consistantly 
reporting  the  status  and  the  results  of  management  action  on  both  the 
project  and  the  organizational  elements. 

4.1.5  Improved  Management  Shills 

Tasks  have  been  identified  which  support  improved  education  for 
project  managers  in  the  use  of  software  engineering  principles,  the 
structuring  of  organizations,  and  project  accounting  and  control. 
Tools  would  be  developed  for  enhancing  and  exercising  of  management 
skills. 

4.1.6  fotgBiiil 

Project  management  could  become  significantly  more  effective, 
using  todays  software  engineering  principles,  by  increasing  the  power 
and  use  of  automated  tools  and  improving  the  timeliness  and  content 
of  project  information  flow.  The  use  of  integrated  software  support 
environments  like  the  Ada  APSE  to  capture  information  about  the 
status  of  project  activities  coupled  with  improved  information  flow 
among  project  participants  on  both  sides  of  and  across  the* 
buyer/producer  interface  could  enhance  project  managers  ability  to 
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understand  program  status.  In  order  to  make  good  use  of  the 
increased  information  availability*  automated  tools  would  be  a  neces¬ 
sity. 

Today,  much  of  the  knowledge  about  sofware  projects  is  captured 
only  in  the  form  of  the  end  product.  Because  the  end  product  is 
designed  to  perform  a  function  and  not  to  relate  the  concepts  and 
decisions  embedded  in  its  evolution*  a  better  way  to  capture  project 
knowledge  is  required.  One  approach  is  through  the  use  of  more  for¬ 
mal  requirements  definition  and  design  methodologies.  The  capture  of 
requirements  in  formal  semantics  and  traceability  of  these  require¬ 
ments  through  a  formal  design  process  not  only  enhances  the  control 
of  the  development  process  but  also  enhances  the  transfer  of 
knowledge  about  the  product  to  those  who  have  need  to  change  it. 

4.2  Priorities 

The  Project  Management  Functional  Analysis  provides  the  baseline 
for  the  rest  of  the  task  area  and  therefore  is  of  the  highest  prior¬ 
ity  within  the  task  area.  In  the  same  way  that  an  understanding  of 
the  Project  Management  Function  is  critical  to  their  performance* 
educating  managers  in  the  principles  of  the  Project  Management  Func¬ 
tion  is  critical  to  their  practice.  The  Development  of  Management 
Skills  Educational  Concepts  must  therefore  be  next  in  task  priority. 
Because  the  automated  tools  can  only  be  developed  based  on  a  clear 
understanding  of  the  functions  which  they  are  to  perform  and  can  only 
be  used  effectively  by  people  who  understand  the  principles  which  the 
tools  are  designed  to  support*  the  development  of  advanced  tools  must 
be  third  in  the  priority  order. 


